The International Telecommunication Union (ITU) sets forth recommendations for interfaces in optical networks in ITU-T Recommendation G.709. This recommendation defines, amongst others, an optical channel data unit (ODUk), an optical channel payload unit (OPUk), and an optical channel transport unit (OTUk). The containment relationship between the ODUk, the OPUk, and the OTUk is well-known and can be summarized as follows: The OTUk comprises the ODUk, which comprises the OPUk, which comprises client frames.
An ODUk frame consists of 4 rows and 3824 columns. An OTUk frame consists of 4 rows and 4080 columns. The first 16 columns of an OTUk frame and of an ODUk frame include a header, and the remaining columns are dedicated to payload. The first 6 bytes of the first row are dedicated to a Frame Alignment Signal (FAS), which is used for delineating OTUk/ODUk frames. The seventh byte represents the Multi-Frame Alignment Signal (MFAS), which is used for indicating the sequence number of an OTUk/ODUk frame out of 256 frames. For the purpose of the present disclosure, an OTUk/ODUk frame can be referred to simply as an OTN frame.
The FAS is defined in the first row of the OTUk/ODUk, at columns 1 to 6, as the following series of OA1 and OA2 bytes: OA1-OA1-OA1-OA2-OA2-OA2; the OA1 byte corresponds to 11110110 and the OA2 byte corresponds to 00101000. The MFAS is at the seventh column of the first row and is simply a binary number comprised between 0 and 255.
According to ITU-T Recommendation G.798—Characteristics of OTN hierarchy equipment functional blocks, the OTUk frame alignment is to be found by searching for the OA1 and OA2 FAS bytes and, the multiframe alignment is to be found based on the MFAS byte comprised in the OTUk frame.
With respect to OTUk frame and multiframe alignment, in the out-of-frame (OOF) state, the framing pattern searched is to be a four-byte subset of the OA1 and OA2 bytes. With respect to OTUk frames, in the context of the present disclosure, the FAS can be said to have four bytes. The in-frame (IF) state is to be entered if this subset is found and confirmed one frame period later. In the IF state, the frame signal is to be continuously checked, with the presumed frame start position, for correct alignment. The framing pattern checked for is the OA1OA2OA2 pattern (bytes 3, 4 and 5 of the first row of the OTUk frame). The OOF state is to be entered if this subset is not found at the correct position in 5 consecutive frames. The frame start shall be maintained during the OOF state.
The OTUk multiframe alignment is to be found based on the MFAS byte contained in the OTUk frame (row 1, column 7 of the OTUk frame). The out-of-multiframe (OOM) state is to be assumed when the received MFAS does not match with the expected multiframe number in 5 consecutive OTUk frames. In the OOM state, multiframe alignment shall be assumed to be recovered, and the in-multiframe (IM) state shall be entered, when, in two consecutive OTUk frames, an error-free MFAS sequence is found. The multiframe start position is to be maintained during the OOM state.
FIG. 1 shows the first sixteen columns and the four rows of an OTUk/ODUk frame, and the position, within the OTUk/ODUk frame, of the FAS, MFAS, OTUk overhead, ODUk overhead, and OPUk overhead.
With respect to ODUk frame alignment, in the OOF state, the framing pattern searched for is to be the full set of the six OA1 and OA2 bytes. The IF state shall be entered if this set is found and confirmed one frame period later and an error free multiframe sequence is found in the MFAS bytes of the two frames.
In the IF state, the frame alignment signal is to be continuously checked with the presumed frame start position and the expected multiframe sequence. The framing pattern checked for is to be the OA1OA2 pattern (bytes 3 and 4 of the first row of the ODUk frame). The OOF state is to be entered if this subset is not found at the correct position in 5 consecutive frames or the received MFAS does not match with the expected multiframe number in 5 consecutive frames.
ITU-T Recommendation G.709 defines a number of ODUk frames, where the order k can be any one of 0, 1, 2, 3, and 4, which correspond to increasing bit rates. A lower rate ODUk can be multiplexed into a higher rate ODUk, thereby, enabling multilevel multiplexing, which allows higher rate clients to carry lower rate clients over the same optical fiber.
The ODUk frame alignment procedure is defined in ITU-T Recommendation G.798. It refers to a receive path, i.e., a sink, and allows for locking to the start of the frame and multiframe, and also allows for extracting overhead and payload from predefined locations. An example of an ODUk sink is shown in FIG. 2. In this example, a high order (HO) client signal, for example, an ODU4 signal 50, is received at a demultiplexer 52 and is demultiplexed into medium order (MO) signals, for example 10 ODU2 signals 54, which are frame aligned by an alignment module 56. The frame alignment module 56 outputs 10 frame-aligned ODU2 signals 58 that can be input into a demultiplexer 60, which demultiplexes the 10 frame-aligned ODU2 signals 58 into low order signals 62, for example, 40 ODU1 signals 62. These 40 ODU1 signals 62 can be frame aligned by a frame alignment module 64, which outputs 40 frame aligned ODU1 signals 66.
As is known in the art, subsequent the demultiplexing of the ODU4 signal 50 by the demultiplexer 52, the 10 ODU2 signals 54, which are medium order signals, need to be frame aligned in order to be able to extract the overhead and payload from each frame. Similarly, subsequent the demultiplexing of the 10 ODU2 signals 58 by the demultiplexer 60, the 40 ODU1 signals 62, which are low order signals, need to be frame aligned in order to be able to extract the overhead and payload from each frame.
In the example of FIG. 2, the ODU4 signal 50 does not need frame alignment because its frame is assumed to be already byte and frame aligned to the OTUk frame. When an upstream block aligns to the OTUk frame, so does the ODUk frame boundary.
FIG. 3 shows another example of where frame alignment may be used. In FIG. 3, LO client signals 68 arriving from an external interface such as, for example, the system fabric 70, need to be frame-aligned, by a frame alignment module 72, before any processing can be performed on the overhead and payload of the frame-aligned client signals 74.
Frame and multiframe alignment is necessary to OTUk/ODUk sink functionality according to ITU-T Recommendation G.798. Modern transport networks require traffic rates in the order of 100 Gbps. The future promises the need for even higher rates of 400 Gbps, 1 Tbps and beyond. Such increases will require that the processor chip architectures to adapt accordingly. A brute force approach described further below leads to a linear increase in logic size, which will negatively impact the size of the hardware required to carry out operations on increasingly high rate signals.
The importance of an efficient frame and multiframe alignment implementation is further emphasized in multistage and multichannel architectures, such as the one shown in the examples of FIG. 2 and FIG. 3. There are multiple points in the architecture where such frame alignment logic is required, thereby further adding up to the number of gates required.
Future, smaller technology node steps promise higher integration with minor improvements in operating frequencies. Thus, devices supporting higher rate clients will likely scale their bus size. For example, a 100 Gbps device with 384-bit wide bus could scale to 3840 bits to support 1 Tbps clients.
In a typical brute force FAS matching approach for a W-byte wide bus, W being an integer, a frame alignment system can be implemented using W×6B matchers, where the 6 bytes (Bs) represent the pattern consisting of OA1 and OA2 bytes of the FAS, as specified in the ITU-T Recommendation G.798.
FIG. 4 shows a block diagram of a framing device that includes 6B matchers 76 combinationally comparing 6 bytes of a W-byte word with the FAS pattern. Each of the 6B matchers 76 outputs a single bit match flag. Assuming a byte-aligned data bus, Wx6B matcher instances are required as the FAS pattern can be found anywhere in the currently processed bus word. As a result, the output of the 6B matchers 76 defines a W-bit wide match vector that has a logic 1 at locations where the FAS pattern has been found and a logic 0 at locations where the FAS pattern was not found.
After the match vector is determined, the next step in the brute force approach of frame alignment is to search the match vector for the first detected occurrence of the FAS pattern. This is performed by a location find device 78. The output of the search of the match vector is a pointer to the location of the first detected occurrence of the FAS pattern, within the bus word. Depending on the design frequency and technology node, more than one stage of registers may be required in order to meet timing requirements. FIG. 4 shows this as two separate stages (stage 1 and stage 2) where the output of the matchers (the output of the matchers defines the match vector) is registered prior to performing a location find operation. Registers are present at the dashed line separating stage 2 from stage 1.
In the location find device 78, each bit of the match vector is processed in parallel with the other bits. Consequently, the frame alignment logic in the example of FIG. 4 is proportional to the size of the bus width. It would be beneficial to be able to increase the width of the bus without having to proportionally increase the size of the location find device 78. Further, when scaling with this approach from 100 Gbps to 1 Tbps, the number of 6B matchers, and thereby the logic, linearly increases by a factor of 10. Therefore, increasing signal rates negatively impacts the dimensional constraints of the physical logic required for frame alignment.
Therefore, improvements in frame alignment are desirable.